Educational adaptive provider architecture

ABSTRACT

The educational adaptive provider architecture described herein provides a way for an educational services framework to be built on varying underlying existing technologies without any changes in the object model and services. The provider framework supports the ability to have multiple types of providers for various services, such as, for example, for authorization, authentication, communication, grouping, scoring, social-networking, storage and user functions. The educational adaptive provider architecture provides easy integration of existing institutional and educational service deployments.

BACKGROUND

Many institutions and educational providers rely on computer systems forteaching classes and providing other types of services. These computersystems often rely on different providers of services to provide themwith, for example, authorization to access their computer system, userauthentication, grouping of various users into work groups, classes andthe like, scoring or assessment of exams or other items, socialnetworking, data storage and other user functions. Institutional andeducational deployments of computer systems are different, and haveexisting underlying technological provider investments which are hard tochange and difficult to integrate and use.

SUMMARY

This Summary is provided to introduce a selection of concepts in asimplified form that are further described below in the DetailedDescription. This Summary is not intended to identify key features oressential features of the claimed subject matter, nor is it intended tobe used to limit the scope of the claimed subject matter.

In general, the educational adaptive provider architecture describedherein provides a way for an educational services framework to be builton varying underlying existing technologies without any changes in theobject model and services. The provider framework supports the abilityto have multiple types of providers for various services, such as, forexample, for authorization, authentication, communication, grouping,scoring, social-networking, storage and user functions. The educationaladaptive provider architecture provides easy integration of existinginstitutional and educational service deployments.

More specifically, one embodiment of the educational adaptive providerarchitecture operates as follows. A request for computer services isreceived from a requester such as a user. For example, the servicerequested might be for authorization to access a computer system, userauthentication, grouping of various users into a class, scoring orassessment of an exams, access to a social networking site or a classthat is being taught, data storage or other user functions. The servicerequest is reformatted into a format required by a pluggable externalservice or service provider of a set of pluggable external serviceproviders. A pluggable service or service provider is one that iscapable of being plugged in without significant interruption to a systemthat is operating. It is a configurable service that does not have to bepreconfigured. (For the purpose of this disclosure the terms pluggableservice and pluggable service provider will be used interchangeably.)Once created, the reformatted service request is then sent to a selectedpluggable external service provider for servicing (e.g., providing theservice requested). The requested service response is then obtained fromthe pluggable external service provider. The requested service responsecan be reformatted into a format usable by the requester, if necessary.The requested service response, either reformatted or not, is thenprovided to the requester.

DESCRIPTION OF THE DRAWINGS

The specific features, aspects, and advantages of the disclosure willbecome better understood with regard to the following description,appended claims, and accompanying drawings where:

FIG. 1 is a flow diagram depicting a generalized exemplary embodiment ofa process for employing the educational adaptive provider architecture.

FIG. 2 is another flow diagram depicting another exemplary embodiment ofa process for employing the educational adaptive provider architecture.

FIG. 3 is another flow diagram depicting yet another exemplaryembodiment of a process for employing the educational adaptive providerarchitecture.

FIG. 4 is an exemplary architecture in which one embodiment of theeducational adaptive provider architecture can be practiced.

FIG. 5 is a schematic of an exemplary computing device in which thepresent educational adaptive provider architecture can be practiced.

DETAILED DESCRIPTION

In the following description of the educational adaptive providerarchitecture, reference is made to the accompanying drawings, which forma part thereof, and which is shown by way of illustration examples bywhich the educational adaptive provider architecture may be practiced.It is to be understood that other embodiments may be utilized andstructural changes may be made without departing from the scope of theclaimed subject matter.

1.0 Educational Adaptive Provider Architecture

The educational adaptive provider architecture described herein providesa way to support multiple provider technologies in the educationaldomain (or other domain for that matter) and provides for the easieradoption of different services and different service providers. It alsohelps extensibility without causing disruption to the applications,services or utilities that are built on existing services and entityarchitectures. The educational adaptive provider architecture providesintegrated transactional-capability, error-handling andcompensation-logic, and also supports providers for (but not limited to)authorization, authentication, communication, grouping, scoring,social-networking, storage and user functions.

1.1 Overview

The educational adaptive provider architecture described herein providesa way to support multiple service provider technologies in theeducational domain. The educational adaptive provider architecture isnot limited to existing service providers (such as, for example, forauthorization, authentication, communication, grouping, scoring,social-networking, storage and user functions), but can also supportadditional providers, such as, for example, custom providers, at thesame time, and provides the ability to add a custom provider for eachpluggable provider category. The architecture also provides a way toturn off an external service provider if, for example, an institutionalcomputer system does not have any provider technology investments inthat provider area or if a software application chooses not to utilize aprovider.

The educational adaptive provider architecture works for cloud hosted(e.g. hosted over a network such as the Internet) and locally-hostedinstitutional scenarios. The architecture employs pluggable externalservice providers, and they can be totally different for differentinstitutional deployments. The architecture helps to seamlesslyintegrate pluggable external service provider technologies into anexisting education services architecture without changes to any exposedApplication Programming Interfaces (APIs). For example: A university mayhave an existing user services provider. The architecture helps toexpose the existing user services provider capability in a consistentand similar manner to other existing services employed in an existingeducational computer system and hence requires no changes in the exposededucation services APIs. If the institution decides to the switch froman existing user services provider to a different user services providersupported by the educational adaptive provider architecture, onlyconfiguration changes are needed to consume the internal and externalservice providers since both external providers are supported in theeducational adaptive provider architecture. Institutions do not have tochange applications, services and utilities that are built on theexisting computer system framework.

1.1.1 Pluggable Provider Framework for Educational Services:

The educational adaptive provider architecture interfaces with pluggableexternal service providers. A pluggable service provider is one that iscapable of being plugged in without significant interruption to a systemthat is operating. It is a configurable service provider that does nothave to be preconfigured. The use of pluggable external serviceproviders allows the architecture to provide the ability to add, changeor remove external service providers for communications, grouping,scoring, social-networking, storage and other user services viaconfiguration settings.

1.1.2 Integrated Transactional Capability

The educational adaptive provider architecture provides the ability tomake provider related operations to be transactional with othereducational service entities and storage operations and with otherexternal service provider based operations. This is due to the fact thatthe services provided by a pluggable external services provider can bereformatted by an internal service provider to present a consistentuser-interface and functionality via one or more application programminginterfaces (APIs).

1.1.3 Provider Compensation Logic Support:

The educational adaptive provider architecture provides additionalcompensation logic for requested external provider operations that areunsuccessful. Details of provider compensation logic support will beprovided later in Section 4.5.

1.1.4 Integrated Error Handling:

The educational adaptive provider architecture provides for integratederror-handling for external provider operations so that errors arepropagated and displayed in a consistent and similar manner to users.This makes it easier for entities to build applications, services andutilities on an educational services framework. Details of integratederror handing will be provided later in Section 4.6.

1.1.5 Easy Integration:

The educational adaptive provider architecture helps institutionsintegrate existing service providers into a common provider framework.In essence, the architecture provides the ability to use and integrateexisting and new institutional providers for authorization,authentication, communications, grouping, scoring, social networking,storage, various user functions, and other services as desired. This isvaluable since most institutions have existing underlying technologicalprovider investments which are hard to change.

1.1.6 Extensibility for Partners and Clients:

The educational adaptive provider architecture provides extensibility toadd, remove, change/swap underlying technologies as needed withoutcausing disruption to the applications, services or utilities that arebuilt on existing computer systems and frameworks. Institutions andpartners can develop their own providers if the existing providers donot meet their requirements. The newly developed providers can be easilyplugged into the provider framework of the present education adaptiveprovider architecture without any code changes.

An overview of the educational adaptive provider architecture havingbeen provided, the next sections will provide a description of exemplaryprocesses for employing the educational adaptive provider architecture,an exemplary architecture in which the architecture can be practiced,and details and alternate embodiments of the architecture.

2.0 Exemplary Processes for Employing the Architecture

The educational adaptive provider architecture can be employed usingvarious processes. Some exemplary processes for employing the adaptiveprovider architecture are described below.

In general, one exemplary process by which the educational adaptiveprovider architecture can be employed is shown in FIG. 1. As shown inFIG. 1, this embodiment of the educational adaptive providerarchitecture operates as follows. A request for computer services isreceived from a requester such as a user, as shown in block 102. Forexample, the service requested might be for authorization to access acomputer system, user authentication, grouping of various users into aclass, scoring or assessment of an exams, access to a social networkingsite or a class that is being taught, data storage and other userfunctions. The service request is reformatted into a format required bya pluggable external service provider of a set of pluggable externalservice providers, as shown in block 104. The format may be obtained,for example, by accessing a list of available pluggable external serviceproviders and associated configurations and data formats. Thereformatted service request is then sent to a pluggable external serviceprovider for servicing (e.g., providing the service requested), as shownin block 106. As shown in block 108, the requested service is obtainedfrom the pluggable external service provider. The requested service canbe reformatted into a format usable by the requester, if required, asshown in block 110. As shown in block 112, the requested service, eitherreformatted or not, is then provided to the requester.

Another exemplary embodiment 200 for employing the educational adaptiveprovider architecture is shown in FIG. 2. In this embodiment a servicerequest for computer services is received from a requester, as shown inblock 202. The type of service request is determined, as shown in block204. For example, the type of service requests can be determined byextracting a field in the service request that specifies the type ofservice requested. Based on the type of service request determined, theservice request is routed to an internal service provider related to thetype of service requested, as shown in block 206. As shown in block 208,the format of the service request required by a pluggable externalservice or a pluggable external component for the type of servicedetermined is obtained. For example, the information can be extractedfrom a file that lists the pluggable external services providers and theassociated configurations. The service request for computer services isthen formatted to be compatible with one of a set of external servicesor external components based on the obtained format, as shown in block210. The formatted service request is then sent to the pluggableexternal service provider or the pluggable external component forservicing, as shown in block 212. The requested service is then providedto the requester, as shown in block 214.

Yet another exemplary embodiment 300 for employing the adaptive providerarchitecture is shown in FIG. 3. In this embodiment, a requester sends arequest for computer services, as shown in block 302. The request forcomputer services is routed to an internal services provider based onthe type of request it is. For example, the service requested might befor authorization to access a computer system, user authentication,grouping of various users into a class, scoring or assessment of anexams, access to a social networking site or a class that is beingtaught, data storage and other user functions. So, as shown in FIG. 3,the service request might be routed to an internal communicationprovider (block 306), a group provider (block 308), a score provider(block 310), a social networking provider (block 312), a storageprovider (block 314), a user provider (block 316) or another type ofservice provider 318. In this example, let it be assumed that theservice request is for communication services and the request issubmitted to an internal communication services provider (block 306).(This path is indicated by darker lined blocks.)

The selected internal service provider determines the type of externalservices provider suited to provide the external service after obtainingthe availability and configuration of the pluggable external serviceproviders (blocks 306, 308, 310, 312, 314, 316, 318). For each type ofservice there can be several pluggable external service providersavailable for selection, as shown in blocks 320, 322, 324 and 326). Oneof these can be a custom provider (e.g., block 320). Any of theseexternal service providers can also be designated as a default serviceprovider. Additionally, one option is a selection of no serviceprovider, in which case no service will be provided by any pluggableexternal service provider (block 322). In this example, it is assumedthat the internal communication provider (block 306) selects the custompluggable external communications provider (block 320). The pluggableexternal service provider is selected based on the configurationobtained by the internal communication provider.

The internal service provider then employs the configuration requiredfor the type of pluggable external service provider, and reformats theservice request for the selected pluggable external service providerselected (as shown in blocks 306, 308, 310, 312, 314, 316, 318). Thereformatted message is sent to the chosen pluggable external serviceprovider that provides the service (e.g., block 322 in this example).The selected pluggable external service provider can provide the servicedirectly to the requester, or the internal services provider canreformat the services as required by the requester if necessary (blocks330, 332, 334, 336, 338, 328, 342).

It should be noted that although the above description generally relatesto authorization, authentication, communication, grouping, scoring,social-networking, storage and user service providers, providers forother services can also be employed with the educational adaptiveprovider architecture.

3.0 Exemplary Embodiment of the Architecture

The exemplary process for employing the architecture having beenprovided, the following paragraphs describe an exemplary embodiment ofan architecture in which one embodiment of the architecture can bepracticed.

FIG. 4 provides an exemplary architecture in which one embodiment of theeducational adaptive provider architecture can be practiced. Thisexemplary architecture (block 400) includes an educational adaptiveprovider module 402 that typically resides on a computing device, suchas for example, the computing device 500 discussed with respect to FIG.5. A request for computer services 404 is input. A determination of thetype of the request is made. For example, a determination is made in aprocess handler 406 that employs a type determination module 408 thatdetermines whether the request is, for example, a communications,grouping, scoring, social networking, storage, or user operations typeof service.

Based on the type of service request, the request is routed to one of aset of internal service providers related to the determined type ofservice request 410. This internal service provider 410 can be relatedto one of, for example, communications, grouping users for differentpurposes, scoring exams or other data, social networking, data storage,and other user operations. The chosen internal service provider of aprovider framework 410 accesses the configuration 414 and provides alist of registered pluggable external service providers, and chooses andinitializes a pluggable external service provider to handle the servicerequest. The chosen internal service provider also obtains theconfiguration of the chosen pluggable external service provider from theconfiguration storage module 414. This configuration will be used, forexample, to configure the service request received into a formatcompatible with a pluggable external services provider. For example, theexternal service provider can be chosen from one or more existingexternal service providers for the determined type of service. Or acustom provider can be selected. Optionally, the internal serviceprovider can choose not select a provider at all for this service, inwhich case no service of the requested type will be provided. Morespecifically, an internal service provider 410 can choose a pluggableexternal service provider 422, 424, 426, 428, 430, 432 related to thetype of service request from the set of pluggable external serviceproviders 420. For each type of pluggable external service providers422, 424, 426, 428, 430, 432 there can be several pluggable externalservice providers available for selection 434, 436, 438. Any of thesecan be a custom provider 440. The pluggable external provider is chosenby the provider framework based on the configuration maintained in theconfiguration storage module 414. One of these pluggable externalservice providers can also be designated as a default service provider.Additionally, one option is a selection of no service provider 434(e.g., a stub is employed), in which case no service will be provided byany pluggable external service provider. The chosen internal serviceprovider can also access any additional information needed from aresource file or files 416.

Once the pluggable external service provider is selected, the choseninternal service provider then reformats the service request inaccordance with the configuration required by the chosen externalservice provider, as shown in block 418.

Once the service request is properly formatted for the chosen pluggableexternal service provider, the reformatted service request is sent tothe chosen pluggable external services provider that provides therequested service 442. Both the initial service request 404 and theprovided requested service 442 can be sent directly to the requester, orcan be sent over a network 412, such as the Internet, for example.

The chosen internal service provider can also interface with the chosenpluggable external service provider to perform error handling andcompensation logic as required, as will be discussed in more detaillater.

4.0 Additional Details and Alternate Embodiments

An overview of the adaptive provider architecture, an exemplaryarchitecture and exemplary processes having been provided, the followingparagraphs provide details and alternate embodiments of thearchitecture.

4.1 Service Request and Internal Provider Details:

As discussed above, the internal service providers reformat servicerequests from a user or other entity into a format recognizable to apluggable external service provider. This provides the ability to add,remove, change/swap underlying technologies and services without causingdisruption to the applications, services or utilities that are built onexisting computer systems and frameworks. Institutions and partners candevelop their own providers if the existing providers do not meet theirrequirements. The newly developed providers can be easily plugged intothe provider framework without any code changes.

4.1.1 Service Request:

As discussed previously, a service request is made for services.Generally such a service request includes the context (who is making thecall), the action that needs to be performed, and the object that theaction needs to be performed on (for example a blog or forum). Forexample, for a request for social networking services the servicerequest would include the user ID of the requester, the ID of the socialnetwork (such as, for example a blog ID), and a request to access thesocial networking site. For a grouping service request (e.g., a requestto be added to a group by a group provider ), the service request mightinclude the user ID, the user login provider ID, as well as thereference of the group, along with the action requested (e.g., to beadded to the group) and the registered application ID making therequest.

4.1.2 Internal Communications Provider

The internal communications provider selects the pluggable externalservice to provide communications services and manages thecommunications with it. To this end, the internal communicationsprovider reformats any communications service request routed to it to becompatible with a pluggable external communications provider. Theexternal pluggable communications provider can provide, for example, thefollowing communications services: send email, create schedule, updateschedule, get schedule, cancel schedule, send message and get message(for e.g. these can be provided by Microsoft® Corporation's Office®Communication Server, Hotmail® and Microsoft® Exchange.)

The internal communications provider also provides error handling andcompensation logic for the chosen pluggable external communicationprovider.

4.1.3 Internal Scoring Provider

The internal scoring provider selects a pluggable external service toprovide scoring services and manages the scoring services provided byit. To this end, the internal scoring provider can reformat any scoringservice request routed to it to be compatible with the pluggableexternal scoring provider. The pluggable external scoring provider canprovide, for example, the following scoring services: scoring, rubrics,analytics retrievals and updates (For example. these are provided withMicrosoft® Corporation's Semblio and Extended Type Service (ETS)).

The internal scoring provider also provides error handling andcompensation logic for the chosen pluggable external scoring provider.

4.1.4 Internal Social Networking Provider

The internal social networking provider selects a pluggable externalservice to provide social networking services and manages the socialnetworking services provided by it. These social networking services caninclude managing access to a course blog or forum provided over anetwork, for example. To this end, the internal social networkingprovider reformats any social networking service request routed to it tobe compatible with the pluggable external social networking provider.The external pluggable social networking provider can provide, forexample, the following social networking services: create blog, createforum (for example, these can be related to Microsoft® Corporation'sCommunity Server, Windows Live™ and SharePoint® team services and portalserver).

The internal social networking provider also provides error handling andcompensation logic for the chosen pluggable external social networkingprovider.

4.1.5 Internal Storage Provider

The internal storage provider selects a pluggable external service toprovide storage services and manages the storage services provided byit. To this end, the internal storage provider reformats any storageservice request routed to it to be compatible with a pluggable externalstorage provider. The pluggable external storage provider can provide,for example, the following file sharing and storage services: add file,add folder, create file, create folder, update file, update folder,delete file, delete folder, get file, get folder, copy file, and movefile (for example these can related to Microsoft® Windows-Live™,Sharepoint®, File Server and Sequence Query Language (SQL).

The internal storage provider also provides error handling andcompensation logic for the chosen pluggable external storage provider.

4.1.6 Internal User Services Provider

The internal user services provider selects a pluggable external serviceto provide user services and manages the user services provided by it.To this end, the internal user services provider reformats any userservices service request routed to it to be compatible with thepluggable external user services service provider. The externalpluggable user services provider can provide, for example, the followinguser services: create user, update user, delete user, and get userprofile (for example, these can be related to Microsoft's®Windows-Live™, Active Directory®, SharePoint® and SQL).

The internal user services provider also provides error handling andcompensation logic for the chosen pluggable external user servicesprovider.

4.1.7 Internal Group Provider

The internal group provider selects a pluggable external serviceprovider to provide grouping services and manages the grouping servicesprovided by it. To this end, the internal group provider reformats anygroup service request routed to it to be compatible with the pluggableexternal group provider. The external pluggable group provider canprovide, for example, the following group services: create group, getgroup information, get group members, update group, delete group, addmember, get member, update member, remove member, and check if a memberis in a group (for e.g. these are tied to Microsoft's® Address-BookClearing House (ABCH)—an online/cloud directory service, ActiveDirectory®, SharePoint® and SQL).

The internal group provider also provides error handling andcompensation logic for the chosen pluggable external group provider.

4.2 Configuration Storage and Initialization

As discussed previously, the selected internal provider reformats thereceived service request message by accessing a configuration databaseor configuration file. The configuration database or configuration fileprovides the configurations of the types of external pluggable serviceproviders available for each type of service and provides the types ofclasses of information available for each type of external pluggableservice provider. In one embodiment of the architecture, theconfiguration file includes provider name, provider type, defaultprovider; and provider properties. For example, an exemplary format of aconfiguration file would be:

<providerTypes> <groupProvider default=“NoOpGroupProvider”>  <providers>  <add name=“ABCHGroupProvider”type=“Education.CoreService.GroupProvider.AbchGroupProvider,MS.Education.CoreServices.GroupProvider” />   <addname=“NoOpGroupProvider”type=“Education.CoreService.GroupProvider.NoOpGroupProvider,MS.Education.CoreServices.GroupProvider” />  </providers> </groupProvider>  <storageProvider default=“NoOPStorageProvider”>  <providers>    <add name=“Live-Storage”type=“Education.CoreService.StorageProvider.WLStorageProvider,MS.Education.CoreServices.StorageProvider” />   <add name=“SkyDrive”type=“Education.CoreService.StorageProvider.SkyDriveStorageProvider,MS.Education.CoreServices.StorageProvider” />   <addname=“NoOPStorageProvider”type=“Education.CoreService.StorageProvider.NoOPStorageProvider,MS.Education.CoreServices.StorageProvider” />   </providers> </storageProvider> </providerTypes>

4.3 Resource File

One or more resource files can be used to provide additional informationnecessary for error handling, compensation logic and other functions. Tothis end a resource file might include: error codes, error messages,request messages, and so forth.

4.4 Decision Logic on Selecting a Pluggable External Service Provider

The internal provider is selected based on the service request type. Theprovider framework (e.g. an internal service provider) chooses apluggable service provider to handle the service request and initializesthe chosen external pluggable service provider based on the previouslydiscussed configuration file.

4.5 Provider Compensation Logic Support:

The educational adaptive provider architecture provides additionalcompensation logic for provider specific operations. The educationaladaptive provider architecture provides additional compensation logic,such as in the case when a pluggable external service provider does nothandle a type of request. In this case the internal service providercalls the necessary function of the chosen pluggable external servicesprovider to undo any change(s) caused by an unsuccessful request toperform a given operation. A call to an external services providertypically has two outcomes: either the operation succeeded or failed. Ifthe operation failed the pluggable external services provider isrequested to undo any changes made by the internal services provider.

4.6 Integrated Error Handling:

The educational adaptive provider architecture provides the ability tohave integrated error-handling tied to provider specific operations sothat errors are propagated and displayed in a consistent and similarmanner to users of any systems employing the architecture. This makes iteasier for entities to build applications, services and utilities on aneducational services framework. Integrated error handling, in oneembodiment, is implemented by maintaining an error code mapping of theinternal error messages and the external services provider errormessages, such as, for example, in a resource file accessible by theinternal service provider. If an error occurs at the pluggable serviceprovider, the error code of the pluggable external services provided isconverted to an internal error message format and presented to the user.If no mapping is found for the pluggable external service provider thena generic provider error is presented.

5.0 The Computing Environment

The educational adaptive provider architecture is designed to operate ina computing environment. The following description is intended toprovide a brief, general description of a suitable computing environmentin which the educational adaptive provider architecture can beimplemented. The architecture is operational with numerous generalpurpose or special purpose computing system environments orconfigurations. Examples of well known computing systems, environments,and/or configurations that may be suitable include, but are not limitedto, personal computers, server computers, hand-held or laptop devices(for example, media players, notebook computers, cellular phones,personal data assistants, voice recorders), multiprocessor systems,microprocessor-based systems, set top boxes, programmable consumerelectronics, network PCs, minicomputers, mainframe computers,distributed computing environments that include any of the above systemsor devices, and the like.

FIG. 5 illustrates an example of a suitable computing systemenvironment. The computing system environment is only one example of asuitable computing environment and is not intended to suggest anylimitation as to the scope of use or functionality of the presentarchitecture. Neither should the computing environment be interpreted ashaving any dependency or requirement relating to any one or combinationof components illustrated in the exemplary operating environment. Withreference to FIG. 5, an exemplary system for implementing theeducational adaptive provider architecture includes a computing device,such as computing device 500. In its most basic configuration, computingdevice 500 typically includes at least one processing unit 502 andmemory 504. The computing device 500 also has a graphics processing unit520 to aid in accelerating graphics rendering, among other functions.Depending on the exact configuration and type of computing device,memory 504 may be volatile (such as RAM), non-volatile (such as ROM,flash memory, etc.) or some combination of the two. This most basicconfiguration is illustrated in FIG. 5 by dashed line 506. Additionally,device 500 may also have additional features/functionality. For example,device 500 may also include additional storage (removable and/ornon-removable) including, but not limited to, magnetic or optical disksor tape. Such additional storage is illustrated in FIG. 5 by removablestorage 508 and non-removable storage 510. Computer storage mediaincludes volatile and nonvolatile, removable and non-removable mediaimplemented in any method or technology for storage of information suchas computer readable instructions, data structures, program modules orother data. Memory 504, removable storage 508 and non-removable storage510 are all examples of computer storage media. Computer storage mediaincludes, but is not limited to, RAM, ROM, EEPROM, flash memory or othermemory technology, CD-ROM, digital versatile disks (DVD) or otheroptical storage, magnetic cassettes, magnetic tape, magnetic diskstorage or other magnetic storage devices, or any other medium which canbe used to store the desired information and which can accessed bydevice 500. Any such computer storage media may be part of device 500.

Device 500 has a display 518, and may also contain communicationsconnection(s) 512 that allow the device to communicate with otherdevices. Communications connection(s) 512 is an example of communicationmedia. Communication media typically embodies computer readableinstructions, data structures, program modules or other data in amodulated data signal such as a carrier wave or other transportmechanism and includes any information delivery media. The term“modulated data signal” means a signal that has one or more of itscharacteristics set or changed in such a manner as to encode informationin the signal, thereby changing the configuration or state of thereceiving device of the signal. By way of example, and not limitation,communication media includes wired media such as a wired network ordirect-wired connection, and wireless media such as acoustic, RF,infrared and other wireless media. The term computer readable media asused herein includes both storage media and communication media.

Device 500 may have various input device(s) 514 such as a keyboard,mouse, pen, camera, touch input device, and so on. Output device(s) 516such as speakers, a printer, and so on may also be included. All ofthese devices are well known in the art and need not be discussed atlength here.

The educational adaptive provider architecture may be described in thegeneral context of computer-executable instructions, such as programmodules, being executed by a computing device. Generally, programmodules include routines, programs, objects, components, datastructures, and so on, that perform particular tasks or implementparticular abstract data types. The educational adaptive providerarchitecture may be practiced in distributed computing environmentswhere tasks are performed by remote processing devices that are linkedthrough a communications network. In a distributed computingenvironment, program modules may be located in both local and remotecomputer storage media including memory storage devices.

6.0 Other Embodiments

It should also be noted that any or all of the aforementioned alternateembodiments described herein may be used in any combination desired toform additional hybrid embodiments. Although the subject matter has beendescribed in language specific to structural features and/ormethodological acts, it is to be understood that the subject matterdefined in the appended claims is not necessarily limited to thespecific features or acts described above. For example, the architecturecan be applied to other types of institutional computer systems besideseducational systems. The specific features and acts described above aredisclosed as example forms of implementing the claims.

1. A computer-implemented process that allows for the use of disparatesoftware services provided in different formats, comprising: receiving aservice request for computer services from a requester; determining atype of the service request; based on the type of the determined servicerequest, routing the service request to one of a set of internal serviceproviders; accessing, by the internal service provider, a list ofexternal pluggable service providers and pluggable external componentsavailable for each type of service request and selecting an externalpluggable service provider or a pluggable external component from thelist; determining if the selected external service provider or theselected pluggable external component is available to render servicesfor the type of service requested, upon determining that the selectedexternal service provider or the selected pluggable external componentis available to render services, obtaining a format of the servicerequest as required by the selected pluggable external service provideror the selected pluggable external component by accessing aconfiguration file that provides the configurations of the types ofexternal pluggable service providers and pluggable external componentsavailable for each type of service request; formatting the servicerequest to be compatible with the selected pluggable external serviceprovider or the selected pluggable external component based on theobtained format; sending the formatted service request to the selectedpluggable external service provider or the selected pluggable externalcomponent for servicing; and providing the requested service forcomputer services from the selected pluggable external service provideror the selected pluggable external component to the requester;otherwise, suspending the rendering of services for the type of servicerequested until the selected external service provider or the selectedpluggable external component becomes available.
 2. Thecomputer-implemented process of claim 1, further comprising reformattingthe requested service provided by the selected pluggable externalservice provider or the selected pluggable external component using theinternal service provider to a format required by the requester.
 3. Thecomputer-implemented process of claim 1 wherein the internal serviceprovider is a communication service provider.
 4. Thecomputer-implemented process of claim 1 wherein the internal serviceprovider is a group service provider.
 5. The computer-implementedprocess of claim 1 wherein the internal service provider is a scoringservice provider.
 6. The computer-implemented process of claim 1 whereinthe internal service provider is a social networking service provider.7. The computer-implemented process of claim 1 wherein the internalservice provider is a storage provider.
 8. The computer-implementedprocess of claim 1 wherein the internal service provider is a userfunction provider.
 9. The computer-implemented process of claim 1wherein the external service, comprises one of a group comprising: anemail service; a calendaring service; a search engine service; a webservice; a scoring engine; a community server; a storage service; adirectory service; or a SharePoint service.
 10. A computer-implementedprocess that allows for the use of disparate software services providedin different formats from different providers, comprising: receiving aservice request for computer services from a requester; determining atype of the service request; based on the type of the determined servicerequest, routing the service request to an internal service providerrelated to that type of service; accessing, by the internal serviceprovider, a list of external pluggable service providers and pluggableexternal components available for each type of service request andselecting an external pluggable service provider or a pluggable externalcomponent from the list; determining if the selected external serviceprovider or the selected pluggable external component is available torender services for the type of service requested, upon determining thatthe selected external service provider or the selected pluggableexternal component is available to render services, obtaining the formatof the service request as required by a pluggable external service or apluggable external component by accessing a configuration file thatprovides the configurations of the types of external pluggable serviceproviders and pluggable external components available for each type ofservice request; formatting the service request to be compatible withone of a set of pluggable external services or the selected pluggableexternal components based on the obtained format; sending the formattedservice request to the pluggable external service or the pluggableexternal component for servicing; and providing the requested service tothe requester; otherwise, suspending the rendering of services for thetype of service requested until the selected external service provideror the selected pluggable external component becomes available.
 11. Thecomputer-implemented process of claim 10 wherein obtaining the format ofthe service request further comprises accessing a configuration filethat specifies the format and information required by the pluggableexternal service or pluggable component for the type of servicedetermined.
 12. The computer-implemented process of claim 11 wherein theconfiguration file further comprises the following information: providername, provider type, default provider; and provider properties.
 13. Thecomputer-implemented process of claim 10 wherein the service requestfurther comprises: identification of the requester; an action that needsto be performed; and the identification of an object the action needs tobe performed on.
 14. The computer-implemented process of claim 13wherein the internal service provider provides compensation logic.
 15. Asystem that allows for the use of disparate software services providedby a number of software service providers, comprising: a general purposecomputing device; a computer program comprising program modulesexecutable by the general purpose computing device, wherein thecomputing device is directed by the program modules of the computerprogram to, input a request for computer services from a requester;determine a type of service request made; based on the type of servicerequest, route the service request to one of a set of internal serviceproviders; access, by the internal service provider, a list of externalpluggable service providers available for each type of service requestand choose an external pluggable service provider from the list;determine if the chosen external service provider is available to renderservices for the type of service requested, upon determining that thechosen external service provider is available to render services, obtaina format of the service request as required by the chosen pluggableexternal service provider by accessing a configuration file thatprovides the configurations of the types of external pluggable serviceproviders available for each type of service request; initialize thechosen pluggable external service provider based on the obtained format;reformat the service request in accordance with the format required bythe chosen pluggable external service provider; send the reformattedservice request to the chosen pluggable external service provider forservicing; and provide the requested service for computer services fromthe pluggable external service to the requester; otherwise, suspend therendering of services for the type of service requested until the chosenexternal service provider becomes available.
 16. The system of claim 15wherein the pluggable external service provider is a default serviceprovider.
 17. The system of claim 16 wherein the pluggable externalservice provider is a stub that provides no service.
 18. The system ofclaim 15 wherein the internal service provider manages one of thefollowing services: communications, grouping users for differentpurposes, scoring exams or other data, social networking, data storage,and user operations.
 19. The system of claim 15, further comprising amodule for choosing a pluggable external services provider, comprising:configuration storage.
 20. The system of claim 15 further comprising amodule for providing error handling compatible with the externalpluggable service providers.